StdCmds.OpenBrowser('Obx/Map', 'Map to the Obx Subsystem')
Quick Start
Oberon/F contains a component framework, which is a new concept for most programmers. This document should give you a quick overview over which kinds of Oberon/F programs there are, when you need which, and where the documentation is.
Generally, Oberon/F distinguishes two main categories of program: commands and views. Commands are comparable to traditional scripts or macros, except that they are implemented in a "real" programming language, rather than in a limited or inefficient special purpose language. This means that if a problem grows, its programmatic solution can grow along; you'll not suddenly need to switch to another language.
Commands
Commands operate on existing data types, e.g. on the built-in texts or forms. They can be regarded as custom extensions of the standard
and
subsystems. This is an important difference to more traditional libraries: new commands dynamically extend the existing functionality of Oberon/F.
Often, programs are built around data entry masks; these are forms in Oberon/F. Very often, you'll also want to generate texts, e.g. for reporting purposes. You can use all capabilities of the Oberon/F text subsystem, including fonts, type sizes, color, embedded components such as stamp views or link views, etc. An example command which uses both the form and text subsystems is ObxOrders0.
Before looking at this advanced example, you may want to have a look at simpler text and form sample programs. The
subsystem ("Oberon by Example") provides a variety of such examples.
Oberon/F programs are document-centric. This means that you typically work with documents and document components; and not directly with files or windows. Files are used only for simple databases or for manipulating legacy data. Sometimes it's possible to convert legacy data to an Oberon/F data type by writing a new converter. Obx also contains an example of such a converter.
The tutorial contains a
section
command
programming
Views
If the built-in subsystems are not sufficient for your purposes, you need to develop a new kind of application. The unconventional aspect about such an application is that it is also just a document component, a so-called view. In contrast to old-style programs, a view only owns a part of a document, and not the whole screen or a whole window. If the view is the outermost (root) view, this cannot be distinguished from a traditional application. However, a view is always able to be embedded in texs, forms, etc.
Examples of views are text views, form views, link views (hypertext), stamp views (time stamps), clock views, Oberon microsystems logo views, bitmap (picture) views, commander views (buttons which execute an Oberon command or sequence of commands), fold views, error views generated by the compiler, various control views (buttons, check boxes, text fields, ...) and so on. Before implementing your own view, take a look at these views to get an idea of the variety of ways that views can be used. Sometimes it's not necessary to implement a whole new complex subsystem, but rather some additional view which extends the functionality of the existing text subsystem, for example.
Views may or may not have a model. A model is the datastructure which is visually represented by the view. In simple cases, where the view needs no editable persistent state, no model is needed. Examples are logo views, commander views, control views, etc. True editors on the other hand should contain a separate model.
Advanced views may contain other views. Such views are called containers. There are three useful categories of containers:
- A Wrapper is a view which contains one or several other views, but no model. Typically, a wrapper has the same size as the wrapped view(s). Wrappers allow to add new functionality to existing views, e.g. a layer wrapper could arrange several views on top of each other.
- A Special Container has a model, which contains the embedded views. The container knows about the types of the embedded views and their layout. Views cannot be inserted or deleted. For example, such a special container could have a query view at the top where database queries can be typed in, and a larger text view at the bottom where the results of the query appear.
- A General Container has a model, which contains the embedded views. This is the most general and most complex kind of view, e.g. the built-in text and form subsystems. The form subsystem is available in source form. Examples for the other kinds of view are available as Obx examples.
Views can be implemented in one or several modules, depending on their complexities.
Views may have no programming interface, a simple procedural interface (typically based on properties, see Controls), or a full-fledged extensible interface. For the latter, it is recommended that the exported interface is separated from the hidden default implementation; for maximum extensibility.
The tutorial contains a
section
programming
The "Wizard"
Apart from the Obx samples and the tutorial examples, another documentation for the most important kinds of Oberon/F programs is available in Dev/Rsrc/New. These are template documents that you can use as basis for your own programs. The template documents' module names are renamed automatically by the Tools->Create
Subsystem... command. This command also creates a suitable new subsystem directory structure (see DevSubTool).
Roadmap
How should you start to get acquainted with Oberon/F? We suggest that after reading the preliminaries, such as the
Guided
and the
User's
Guide
, you continue with the following texts:
Preface
Introduction
Overview
Afterwards, you may read the two tutorial texts:
Tutorial
Command
Programming
Tutorial
Programming
As an alternative, you may first want to go through the sample code, and read the tutorial texts afterwards:
(.txt)